Parking data collection systems and methods

ABSTRACT

A system of parking data aggregation and distribution may comprise a plurality of parking sensors, at least one of the plurality of parking sensors located proximate a parking area and one or more gateway devices. The system may further comprise an administrator interface, a parking operator dashboard interface, and a cloud service component. The cloud service component receives parking sensor data indicating occupancy and turnover from the gateway devices and transmits the parking sensor data to the parking operator dashboard web interface. The cloud service component may comprise a database for storing the parking sensor data and a software application for implementing an algorithm to create one or more predictions for future occupancy and future turnover during a future time period. The parking operator dashboard interface may display one or more representations of the parking sensor data over the past time period and predictions for future occupancy and future turnover.

PRIORITY

This application is a continuation of U.S. Non-Provisional applicationSer. No. 15/286,429, entitled “PARKING DATA AGGREGATION ANDDISTRIBUTION,” filed Oct. 5, 2016, which claims priority to U.S.Provisional Application No. 62/237,350, filed Oct. 5, 2015, entitled“PARKING DATA AGGREGATION AND DISTRIBUTION.” The entire disclosures ofwhich are incorporated herein by reference for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems, methods, and apparatuses forcreating efficiency in parking systems. In particular, but withoutlimitation, the present disclosure relates to capturing and deliveringparking data.

BACKGROUND OF THE DISCLOSURE

In densely populated urban areas, parking loss, garages, and othersimilar parking structures are necessary to fit all the cars that arriveat all the businesses and residences. Often, parking is atime-consuming, frustrating, and expensive experience for consumers.Operators of these parking structures can compete for parking businessthrough several factors, some of which are within their control, andothers which are not. These factors include the location of thestructure relative to desirable establishments, ease of parking, safety,and price, among other things. One of the more easily controlled factorsis price, and sometimes parking operators change their pricing based onexternal factors, such as the time of the day or week, or the occurrenceof special events such as sports games and concerts, in order to attractcustomers over their competitors.

For consumers, there are several sources of frustration related toparking. Sometimes consumers are not able to find a parking spot, evenin a paid garage, which causes them to waste time and fuel. Some studiesestimate that up to 47,000 gallons of gas are wasted per month in majormetropolitan areas while consumers are driving around looking forparking spots. Similar studies estimate that up to 30% of city trafficis due to consumers looking for parking. Another challenge that facesconsumers is that payment acceptance mechanisms vary widely and may notsuit a consumer's needs. Many parking structures require cash—and some,such as those with old parking meters, require actual coins. Some of themore antiquated systems have consumers stuff bills into a slot of alockbox. Others have central payment kiosks, which have their own setsof problems, such as credit card reader malfunctions, confusing userinterfaces, and long lines. Once a consumer has figured out how to payfor parking, an additional source of frustration is paying too much forparking itself. Signs are often confusing and hard to read, and thoughconsumers often try to make the most practical and economical parkingdecision, many consumers know the annoying feeling of walking out of aparking garage in which they just parked, only to discover that justacross the street was a parking structure that was closer to theirintended destination and also a few dollars cheaper.

For parking operators, trying to maximize revenue has its ownchallenges. Once a parking structure is built, there is little that canbe done to change the physical attributes of the space if challengesarise due to congestion in the area or due to problems within thestructure itself. For example, if a new office building gets built nextto the parking structure when there was not one before, the design ofthe structure may not be ideal to handle the influx of customers duringcertain morning hours. If the top floor of a parking structure is poorlydesigned to allow cars to exit, a bottleneck could be created thataffects cars parking on the floor below. Changing prices to adapt tospecial events or weather can be a challenge as well, with mostoperators simply guessing what price would be best at a particular timein order to maximize revenue. Effective enforcement can also be anissue, requiring a human parking enforcement officer to consistentlypatrol a lot. If the method of enforcement is having an officer patroleach spot and then check to see if the spot has been paid for, therewill inevitably be delay between when a car's time expires and when theparking enforcement officer discovers the payment violation. Therefore,several needs exist relating to gathering and using parking data.

SUMMARY

An aspect of the present disclosure provides a system for parking datacollection and aggregation. The system may comprise a plurality ofparking sensors, at least one of the plurality of parking sensorslocated proximate a parking area and one or more devices incommunication with the plurality of parking sensors. The system mayfurther comprise an administrator interface, a parking operatordashboard interface, and a cloud service component, wherein the cloudservice component receives parking sensor data indicating occupancy andturnover from the one or more gateway devices and transmits the parkingsensor data to the parking operator dashboard web interface. The cloudservice component itself may comprise a database for storing the parkingsensor data and a software application for implementing an algorithmthat compares the parking sensor data for a past time period to one ormore external factors to create one or more predictions for futonsoccupancy and future turnover during a future time period. The parkingoperator dashboard interface itself may displays one or morerepresentations of the parking sensor data over the past time period andthe one or more predictions for future occupancy and future turnover ofthe algorithm.

Another aspect of the present disclosure provides a method for providingpredictive parking data. The method may comprise collecting occupancyand turnover for a plurality of parking spots and receiving informationabout one or more external factors from one or more application programinterfaces. The method may further comprise comparing the occupancy andturnover data for a past time period to the one or more external factorsto create one or mate predictions for future occupancy and futureturnover during a future time period and displaying the one or morepredictions for future occupancy and future turnover on a graphical userinterface.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an overview of a system for parking data aggregation anddistribution in accordance with the present disclosure

FIG. 2 shows a parking sensor and sensor mount in accordance with thepresent disclosure.

FIG. 3 shows a logical block diagram of a parking sensor of the systemin accordance with the present disclosure.

FIG. 4 shows a logical block diagram of a gateway device of the systemin accordance with the present disclosure.

FIG. 5 shows a logical block diagram of a cloud service component of thesystem in accordance with the present disclosure.

FIG. 6 a high-level view of inputs, algorithmic factors, and outputsalgorithms for predicting occupancy and turnover of the presentdisclosure.

FIG. 7 shows a graphical user interface with an exemplary parkingoperator dashboard of the present disclosure.

FIG. 8 shows a graphical user interface with an exemplary overviewdisplay version of a parking operator dashboard of the presentdisclosure.

FIG. 9 shows a graphical user interface with an exemplary display ofhistorical and predicted occupancy and turnover.

FIG. 10 shows a graphical user interface with an exemplary display ofdetails of impact events that may be used to predict occupancy andturnover.

FIG. 11 shows a graphical user interface with an exemplary display of aspreadsheet with spot-level detail of parking sensor informationcollected through the system of the present disclosure.

FIG. 12 shows the spreadsheet of FIG. 11 sorted by a selected criteria.

FIG. 13 shows a graphical user interface with an exemplary display thatallows a parking operator to view information for multiple parking areasand select a lot to view more detailed information.

FIG. 14 shows a graphical user interface with an exemplary displaycomparing a parking operator's business goals to actual performancemetrics gathered by parking sensors of the present disclosure.

FIG. 15 shows a graphical user interface with an exemplary display thatallows a parking operator to select a date range and view customizedparking data.

FIG. 16 shows a logical block diagram of a computing system that mayimplement aspects of the present disclosure.

DETAILED DESCRIPTION

One aspect of the present disclosure provides a system for collectingoccupancy and turnover data for parking spots in a parking structure,creating predictions based in part thereon, and displaying such parkingarea information that it can be utilized by both parking operator andconsumers. The term “parking structure” or “parking area” may be usedherein to describe a physical building, garage, or subterraneanenclosure containing many parking spaces, but may also refer to a flatparking lot, a group of metered parking spaces on a street, or any groupof parking spaces that are owned and operated by a parking operator.FIG. 1 shows a diagram of various components of a parking datacollection and aggregation system 100. The parking system 100 of thepresent disclosure may comprise a plurality of parking sensors100A-100G, one or more gateway devices 120, a cloud service 130, anadministrator interface (“administration”) 140 and a parking operatordashboard 150, each of which will be described in further detailthroughout this disclosure. Optional aspects of the system 100 mayinclude one or more consumer personal communication devices 160 with aconsumer parking application. Though interactions between only oneparking sensor 110A and other components of the system 100 are shown,and though only a few parking sensors 110B-110G are depicted, it is tobe understood that this diagram is for illustration purposes only, andthat many more parking sensors (e.g., hundreds or thousands), gateways,and/or consumer computing devices may be used in embodiments of thepresent disclosure.

One component, of the system 100 comprises the plurality of parkingsensors 110A-110G, each of which may be located in an individual parkingspot and collect data regarding vehicles that occupy the spot. In manyembodiments, a parking sensor may be designed to be installed on thesurface of the parking spot without being embedded into the asphalt orconcrete. An advantage of installing a parking sensor above-ground isthat installation costs for a parking operator may be greatly reduced ascompared to installing sensors in the ground, due to the fact that noholes will have to be drilled or jackhammered into the parking lotsurface. In other embodiments, parking sensors may be installed byrecessing them into the ground, if desired. FIG. 2A shows an exteriorview of an exemplary parking sensor 210 according to the presentdisclosure. As shown, the exterior housing of the sensor may becomprised of a durable material such as ABS plastic, which may bedesigned to withstand extreme temperatures, precipitation, and theweight of a large vehicle. It is contemplated that many other materialsmay be used, including other types of plastics and metals. In manyembodiments, the parking sensor 200 may be cylindrical, with a diameterof approximately four inches and a height, of approximately one inch.The relationship between the diameter and the height of the outerhousing may contribute to weight bearing capacity of the parking sensor.

The system may also comprise a surface mount ring 220, as shown in FIG.2B. The surface mount ring 220 may comprise a cylindrical ring structurewith an inner radius 230 and an outer radius 240. The inner radius 240may comprise outer portion, of a circular opening designed to snugly fitthe outer circumference of the parking sensor. As shown, the surfacemount ring 220 may be approximately the same height as the parkingsensor at the inner radius 230 and slope downward toward the outerradius 240. The surface mount ring 220 may be made out of a durableplastic or other suitable material that can withstand extremetemperatures and the weight of large vehicles. An advantage of thesloped design of the surface mount ring 220 is that it may preventpedestrians from tripping over the parking sensor itself. Additionally,it may protect the edges of the sensor turns damage and wear when it isrolled over by a vehicle. The surface of the surface mount ring 220itself may comprise ridges or patters, and may be brightly colored,which may prevent pedestrians from slipping on the surface mount orparking sensor if either are wet.

The parking sensor 210 has several functions, including detecting when avehicle occupies or leaves a spot, relaying the occupancy information toa gateway, detecting BLE-enabled devices when the spot is occupied,connecting with appropriate BLE devices, and providing informationobtained through the BLE devices to the gateway. In order to carry outthese functions, the parking sensor 210 may comprise a number ofinternal components. FIG. 3 is a logical block diagram of a parkingsensor 310 in accordance with the disclosure. This logical block diagramis not to be construed as a hardware diagram, though it may beimplemented in hardware or a combination of software and hardware. Asshown in FIG. 3, a parking sensor 310 may comprise a sensor 320, one ormore radio transceivers 330, a power source 340, a processor 350 andcircuitry to connect the components. The sensor may be implemented by amagnetometer in some embodiments and be used to accurately detect thepresence of vehicles as they occupy and leave parking spots. Anadvantage of using a magnetometer over other kinds of sensors is that ahigh degree of detection accuracy can be achieved at a low cost. It iscontemplated that in some embodiments, the sensor 320 may be implementedby other sensors, such as infrared, radar, and ultrasonic sensors inorder to achieve benefits in accuracy and cost. Magnetometers are knownto be able to reliably detect large pieces of metal up to several feetaway, so they are useful for the specific application of detectingwhether vehicles (which comprise large pieces of metal) are present inparking spots. In many embodiments, a three-axis magnetometer may beused in order to detect vehicles at various angles in relation to thesensor. A three axis magnetometer may be more accurate than a singleaxis magnetometer for detecting small vehicles such as motorcycles.

In general, magnetometers work by detecting the change in the earth'smagnetic field by metal objects in the area of the sensor. It is knownthat the earth's magnetic field varies across different locations on theearth's surface. In applications of the present disclosure, where amagnetometer is used to detect the magnetic field of a vehicle, suchchanges in the earth's magnetic field could potentially causemalfunctions and false readings if the magnetometer were not calibratedfor the particular geolocation. In order to prevent such malfunctions orfalse readings, the magnetometers in pinking sensors of the presentdisclosure may be configured and/or calibrated remotely (e.g., by anadministrator via a remote server) to adjust their sensitivities. Aswill be described later in the disclosure, the magnetometer in eachparking sensor may send its raw magnetometer data to the gateway, whichmay in turn send that magnetometer data to the cloud service. With thisraw magnetometer data, the precise magnetic field at a particulargeolocation of a sensor may be measured. The cloud service may relaythat information to the administrator interface, and an administratormay configure the sensitivity of each magnetometer. In some embodiments,the sensitivity of each magnetometer may be calibrated automatically bythe cloud service in response to each magnetometer's measurement of itslocal magnetic field.

When the sensor 320 senses the presence of a vehicle, the informationthat the spot is occupied may be sent through a radio transceiver 330 toa network-connected gateway device (e.g., gateway 120), which in turnmay relay the information to a cloud service (e.g., cloud service 130).Each of these components of the system 100 will be described in turn.The radio transceivers 330 may comprise a Wi-Fi radio, a cellular dataradio, a short-range communication protocol radio such as RF 434 MHz,Bluetooth, Bluetooth Low Energy (BLE), or Zigbee, or any other type ofradio transceiver suitable for sending and receiving as messagesdescribed herein. Because the sensors are designed to conserve energy inorder to be low-maintenance, many embodiments will employ radiocommunication protocols that require low amounts of energy, such as BLE,which is a commonly-used communication protocol at the time of thisdisclosure. However, the present disclosure is not limited toembodiments utilizing BLE.

Referring back to FIG. 1, One aspect of the present disclosure is thateach parking sensor 110A-110G may send periodic information updates tothe gateway 120. Such, updates may be referred to as “heartbeats,” toindicate that they are sent at regular intervals, and with particularkinds of content every time. The gateway 120 may comprise a physicaldevice with one or more radio transceivers, which has a primary purposeof receiving messages from the plurality of parking sensors within aparticular geographic location, relaying the messages to the cloudservice 130, and sending other messages to back to the plurality ofparking sensors 110A-110G.

FIG. 4 shows a high-level logical block diagram of a gateway device 400in accordance with the present disclosure. The gateway device 400 maycomprise a power source 410, a memory 420, a processor 430, and atransceiver (e.g., radio) 450. It is contemplated that in manyembodiments, the gateway device 400 may comprise more than one kind oftransceiver 450, and may include both a local transceiver 440 and along-range transceiver 445. For example, a certain type of radiocommunication protocol, such as a 433 MHz RF transceiver, may bewell-suited for receiving the heartbeats from the parking sensors110A-110G because the parking sensors 110A-110G are within theprotocol's transmission range of the gateway 400, and because the radioprotocol uses a low amount of power. Therefore, the gateway device 440may be equipped with at least one RF 433 MHz radio as its localtransceiver 440. However, the gateway 400 may be equipped withadditional different radios, such as a Wi-Fi or a cellular radio as itslong-range transceiver 445, in order to connect to the internet andrelay information gathered from the parking sensors 110A-110G to thecloud service 130. A Wi-Fi or cellular data connection may be desirablein order to transmit large amounts of data from gateway 120 to the cloudservice 130, which may be located on a remote server connected so theinternet. The gateway 120 may use a Wi-Fi connection to communicate withother gateway devices in a particular parking structure having more thanone gateway device. In such implementations, one of the gateway devicesmay be responsible for transmitting information from multiple gatewaydevices to the cloud service 130, or more than one of the gatewaydevices may be responsible for transmitting information to the cloudservice 130.

In many embodiments of the system, there will usually be a large numberof parking sensors in communication with any one particular gateway. Asdiscussed previously, each parking sensor may send heartbeats withparking senior information to the gateway. This heartbeat informationmay comprise a unique sensor ID, sensor status (e.g., information notingthat the sensor is operational/functional) and the parking spot status(e.g., information noting that the spot is occupied or unoccupied). Eachsignal transmission from a parking sensor to the gateway may takeseveral seconds. The heartbeats may be sent at intervals of every fewminutes (e.g., every five minutes), but these intervals may be adjustedto be longer or shorter. Because each gateway comprises a finite numberof radios, and has a finite capacity to receive multiple signals atonce, it is contemplated that each of the plurality of sensors may beset to send their heartbeats at intervals staggered from one another. Bydoing so, a single gateway device may be able to constantly receivemessages than several hundred sensors or more.

In addition to the heartbeat information that is sent by the sensorsevery few minutes, the sensors may also periodically send “system statusinformation,” which may comprise information such as battery voltage,raw magnetometer data, the temperature of the sensor, BLE radioinformation, link quality measurements, and error rates. In someembodiments, this system status information may be sent along with theheartbeat, but sending all of that information in one transmission mayresult in a very long packet that takes a long time to transmit. Thelonger the transmission of each packet, the fewer or sensors cancommunicate with the gateway device. Therefore, in some embodiments ofthe disclosure, system status information may be sent at separate timesthan the heartbeat information. The interval between transmissions ofthe system status information may be longer than those betweenheartbeats, because the system status information may not be needed asoften as heartbeat information. The staggering of the intervals and theseparation of information in separate packets can maximize the amount ofsensors that can communicate with a given device, and requires that thegateway device be able to support different sized packets at differentintervals. In many embodiments, heartbeat information and system statusinformation may be encrypted for security purposes using any knownencryption method.

Another aspect of the communication between the parking sensors110A-110G to the gateway device 120 is that acknowledgement (ACK)packets may be utilized to send commands from the gateway device 120back to sensors 110A-110G. For example, each heartbeat message from asensor (e.g., sensor 110A) to the gateway device 120 may contain thesensor ID, the sensor status information, and the parking spotinformation. Typically, in many communication protocols, the gatewaydevice sends an ACK packet to acknowledge receipt of the initialmessage. The ACK packet would typically contain the sensor ID as well(e.g., in a header). In aspects of the present disclosure, the ACKpacket may also contain, in the body of the packet, a command to theprocessor of the parking sensor (e.g., the microcontroller/processor 350of FIG. 3). This command in the body would exist in addition to theacknowledgement of receipt itself that would ordinarily be contained inthe body. Such a command may include a command to calibrate themagnetometer, or change a communication channel, for example.

An advantage to sending a command in an ACK packet is that thetransceiver of the parking sensor does not have to be on and listeningat all times in order to receive commands. In many 2-way communicationprotocols, a transceiver must be on at all times in order to receivemessages. In embodiments of the present disclosure, the transceiver canbe off most of the time, and just turn on during the times it is goingto transmit information (either heartbeat information or system statusinformation). The transceiver can remain on just long enough to receivean ACK packet in response. In this manner, effective 2-way communicationcan be achieved (though it may be limited to certain time intervals) viaa 1-way communication protocol, all while saving significant batterylife.

Again referring to FIG. 1, when a vehicle enters a spot and themagnetometer of the parking sensor 110A detects the vehicle, the BLE (orother) radio may be turned on to scan for BLE-enabled devices within theproximity of the sensor 110A. The BLE radio may be turned off at allother times in order to conserve power. The BLE radio may scan for aconsumer's personal communication device, such as a smartphone 160, inorder, to communicate with parking applications on the smartphone 160. Anumber of smartphone applications for facilitating consumer parking areavailable, and the system of the present disclosure may be utilized withmany of them. The BLE radio of parking sensor 110A may communicate theparking spot's ID number, or any other relevant information, in order tofacilitate payment for the correct parking spot through the application.In other embodiments, vehicles may be equipped with BLE-enabled parkingpasses for pre-paid parking spots. In such embodiments, the BLE radio ofthe parking sensor 110A may simply verify that the BLE-enabled parkingpass is authorized to park in that particular spot. In some embodiments,the status of the parking spot may be sent to the gateway device 120 atthe next scheduled interval for a heartbeat message. In otherembodiments, an information detection message may be sent right away,regardless of when the next scheduled heartbeat interval was to occur,in order to improve the timeliness and accuracy of the spot statusinformation. When a vehicle leaves a parking spot, the magnetometeragain defects the movement and may transmit the updates status of thespot (i.e., unoccupied) to the gateway 120, either at the next scheduledheartbeat interval or immediately through a third kind of transmissionknown as an “information detection” message. Upon the entering andexiting of the vehicle from a spot, the occupancy status of the spot maybe correlated to payment information at the cloud service 130. Bycorrelating the payment information to the occupancy status, the parkingoperator may be notified immediately through the parking operatordashboard 150 if there is a payment violation, which allows the parkingoperator to take immediate action.

It is contemplated that embodiments of the present disclosure mayoperate without a BLE radio (or other similar short-rage communicationprotocol radio) at all. That is, although the BLE radio may beimplemented in some embodiments particularly for the purpose of allowingthe parking sensor to communicate with a consumer personal communicationdevice, this functionality is not required to implement other aspects ofthe disclosure. For example, the parking sensors 110A-110G, the gateway120, the cloud service 130, and the parking operator dashboard 150 maystill gather spot occupancy data and present it to a parking operatorvia an RF radio transceiver, Wi-Fi and/or other TCP/IP connectionsalone.

As all the parking sensors 110A-110G periodically send information tothe gateway 120, the gateway 120 may relay all the gathered informationto the cloud service 130. FIG. 5 shows a high-level logical blockdiagram of the cloud service 500. The cloud service 500 may comprise oneor more databases 510 for storing parking data, such as occupancy andturnover data, from parking sensors via gateways. It is contemplatedthat parking data may be stored for a particular period of time in orderto create historical averages of the parking data. Given that eachindividual parking area can have hundreds or thousands of individualparking spots and sensors, and each of the sensors may send multipleparking data points each day, the number of parking data points overtime can easily become voluminous, numbering into the millions,billions, or more. Therefore, it is contemplated that large commercialdata centers may be implemented as the databases 510 of the cloudservice 500. The could service 500 may also comprise one or moresoftware applications 520 and one or more application programsinterfaces (API's) 530. The APIs will be described in more detail laterin this disclosure. The applications 520 may be execute managing andorganizing received data, sending and receiving commands to and fromvarious devices within the system, and executing instructions providedthrough the administration interface 140, the parking operator dashboardinterface 150, and through the consumer personal communication device160, and implementing predictive algorithms. The predictive algorithmsof the present disclosure will be described in more detail presently,but in general, the software applications 520 may use informationreceived from parking sensors, information stored in the databases 510,information received from the parking operators, and informationreceived through the APIs 530 in order to formulate predictions. It iscontemplated than in many embodiments, the information sent from thegateway 120 to the cloud service 130 may be encrypted via a defaultsetting.

As one example of the function of the cloud service 500, if may receiveinformation from the consumer computing device 150 that includes paymentinformation for the particular parking spot of sensor 110A, which mayinclude the time period for which the consumer has paid. It may alsoreceive corresponding information from the gateway 120 about whether thespot associated with sensor 110A is occupied. The cloud service 130 maycompare the information received from both sources to determine if theconsumer has paid for the correct amount of time. The cloud service maybe able to determine, for example, if the amount of time the consumerhas paid for has expired, and if the spot is still occupied. The cloudservice may then send this information to the parking operator dashboard150 to alert the operator for parking enforcement.

It is contemplated that the cloud service 130 may be a centralized cloudservice that receives information from multiple gateways, which may spanacross multiple parking structures, cities, states, or countries. Thecloud service 130 may expose one or more APIs to third-party computerapplication developers to allow access to information on particularparking structures. By exposing these APIs, the cloud service 130 andthe aggregated data therein may be accessed for the particular needs ofa mobile parking application and the consumers who use it. Therefore,the data aggregated by the system of the present disclosure may beavailable so consumers as well as parking operators, but in differentways. Consumers may be able to see which parking structures haveavailable spots, how much spots cost, and parking lot rules andrestrictions through their application user interfaces. In manyembodiments, the applications may display spot-level maps that showexactly which parking spaces are unoccupied in real-time. In otherembodiments, the APIs may provide information about multiple parkingspots within the parking garage that may be displayed on signs inside oroutside the parking garage. For example, a sign outside a parking garagemay display a percentage of occupancy of the total garage, and signs ineach level may show a map of open and occupied spots. Consumers may beable to enter a desired destination address in advance of their arrivalto plan out their parking, or they may use their current location todetermine where there are nearby spots. By having this informationaccessible, consumers may make informed decisions about where to park,and may waste less time and fuel finding parking. Consumers may also beable to pay for parking spaces while at their parking spaces, orremotely, thereby avoiding machine malfunctions, payment lines, andparking violations. Various applications that, may interface with thecloud service 130 of the present disclosure may be implemented instandalone consumer communication devices such as smartphones orwearables, or may be implemented in vehicle dashboards themselves.

As previously described, the cloud service 500 implements a number offunctions relating to data aggregation and distribution, and usesalgorithms to provide predictive information based in part on the dataacquired through the system. FIG. 6 is a logical diagram of the inputs,algorithmic factors, and outputs of the algorithms of the presentdisclosure. As shown, the inputs can include parking data that is bothcurrent and historical, which include current/historical occupancy data610 and current/historical turnover data 620. For the purposes of thepresent disclosure, “occupancy” can be defined as a measure of whetherany vehicle occupies a spot, and for how long. For example, if one spotis occupied by any vehicles for 50% of the time during a particular day,the occupancy for that spot would be “50% per day.” This percentagewould be the same whether it was one vehicle parked in the spot for halfof the day, or several vehicles who occupies the spot for a few minutesor hours at a time which added up to 50% of the time for the day.“Turnover” can be defined a measure of how many times an individualvehicle entered and then exited a spot, and can also be measured overtime. For example, if four vehicles enter and exit a spot in oneparticular day, the turnover can be quantified as “4 per day.” Eachmeasure may be useful to a parking operator, because revenue may be tiedto both the number of individual customers as well as the time spent byeach customer.

The quantity of data collected by parking sensors over time for eachindividual spot and parking area may be vast, with millions of datapoints being collected even for a single parking structure. In just asingle parking spot, in the course of one day, the parking sensor forthat spot can collect the following pieces of information: 1) how manytimes vehicles entered and exited the spot (generally correlating to howmany different individual vehicles occupied the spot), 2) how long eachvehicle occupied the spot, 3) what times the vehicle occupied the spot,and 4) how long a spot remained empty. This data may continuously becollected over time and used in beneficial ways. The raw data regardingoccupancy and turnover may be referred to as “current” and/or“historical” data, and both may be useful to a parking operator. As willbe shown later, current data may be displayed on a graphical userinterface, and may be compared to historical data. When this data iscollected over the course of more than one day, the cloud service canimplement simple algorithms such as averaging the number of vehicles perspot, per day, and based on the average for that spot, predict theaverage number of vehicles in that spot on days in the future. An aspectof the present disclosure is that the data collected by the parkingsensors may be used to accurately predict demand (i.e., future occupancyand turnover) for parking in a particular parking area at particulartimes. Hence, the current/historical occupancy data 610 andcurrent/historical turnover data 620 is shown as measured in time (e.g.,hours of the day or elapsed time), day, week, month, and year.Similarly, the output occupancy prediction 670 and turnover prediction680 is also provided in terms of time, day, week, month, and year.

The complexity of making accurate predictions increases significantly asadditional factors are added to the algorithms in the presentdisclosure. FIG. 6 shows that various algorithmic factors are taken intoaccount at the cloud service 640. Each factor may influence whether thevarious predictions provided are increased or decreased. The followingfactors may be considered to increase or decrease predicted values invarious embodiments:

-   -   a. Day of the week 641: Algorithms of the present disclosure may        weigh days of the week either as one of two categories (weekday        and weekend) or into the seven separate days. The data collected        by parking sensors may be compared to the days of the week in        which it is collected on the cloud service 640. This information        may effect a predictive algorithm in a number of ways that may        differ between different parking areas. For example, certain        parking areas may be busier on weekdays than weekends, and        busier on Mondays than Fridays, if they are in business        districts. As another example, a performing arts center parking        area may be busier on a weekend than a weekday.    -   b. Time of day 642: The data collected by she parking sensors        may be compared so the time of day during which it is collected        on the cloud service. Predictions may factor in time periods        like morning and evening rush hours, business hours, or may        individually track occupancy and turnover on an hour-by-hour        basis, for example.    -   c. Calendar date 643: The data collected by the parking sensors        may be compared to a calendar date in which it collected on the        cloud service. Calendar dates may provide insight into occupancy        and turnover patterns on holidays, patters that are dependent on        seasons, and can be used to compare patterns on a year-over-year        or month-over-month basis.    -   d. Events 644: Events such as concerts, meetings, conventions,        or sporting events that are scheduled to occur within a certain        geographic radius of a parking area may be provided through an        external events API. Events associated with a large number of        vehicles may be used to increase one or more prediction values.    -   e. Weather 645: External, weather service data may be provided        to the cloud service through an API. Bad weather events, such as        freezing temperatures, snow, rain, hail, or storms may be used        to provide predictions for lower occupancy and turnover when        combined with historical parking data. Similarly, good weather        can be used to provide predictions for higher occupancy and        turnover when combined with historical parking data.    -   f. Traffic 646: Traffic data may also be provided to the cloud        service through an external API. In some instances, greater        traffic in certain areas may be correlated with increased        occupancy and/or turnover. For example, some traffic patterns        near a parking area may indicate greater demand for parking. In        other instances, it may be greater traffic may be correlated        with decreased occupancy and/or turnover. For example, some        traffic patterns may indicate that vehicles may be blocked, from        entering a parking area.    -   g. Business goals 647: The parking operator 615 may input        certain business goals related to occupancy, turnover, pricing,        revenue, citations, or any other measurable objective. The        business goals may be a metric against which actual performance        data is compared. The performance metrics 660 shown as an output        may be based on business goals entered by the parking operator.

In addition to occupancy predictions 670, turnover predictions 680, andperformance metrics 660, the algorithms of the present disclosure mayalso provide pricing recommendations 650. Increases in pricing (whichmay also be known as “surge pricing”) can be suggested to the parkingoperator based on predictions of increased occupancy and/or turnoverduring a particular time period. Surge pricing may also factor in theparking operator's business goals in order to increase the likelihoodthat a particular goal will be hit in response to the surge pricing. Itis contemplated that surge pricing recommendations may be implementedautomatically in certain embodiments.

One main benefit to implementing the algorithms of the presentdisclosure by using large amounts of collected data from parking sensorsis that predictions can become more refined and accurate over time.Take, for example a parking area in which parking sensors and the systemof the present disclosure are installed for the first time. On the firstday, the parking sensors will be collecting data, but will not haveprevious data for the particular parking area to which if may comparecurrent data. Therefore, the predictions the algorithms can provide maybe limited in accuracy. It is contemplated that even on a “first day,”the algorithms may still have default settings from which to basepredictions. For example, even on a first day of collecting data, thealgorithm may have weather information, event information, and trafficinformation. A default algorithm related the weather information couldbe a simple one such as: “if the weather as sunny and 72° now, and it ispredicted to rain later this afternoon, the predicted occupancy andturnover compared to now will be 25% less.” As another example, adefault algorithm related to an event could be “if there is no eventnow, but there is a concert 0.5 miles away in three hours, the predictedoccupancy and turnover compared to now will be 50% more.”

As the system collects more actual parking data over time, though, anydefault assumptions of the algorithm may be programmed to change. Forexample, over a period of six mouths, actual data may show that rain inthe forecast reliably predicts a 10% increase in occupancy and a 10%decrease in turnover. It may also show that snow predicted in theforecast reliably predicts a 30% increase in occupancy and turnover. Itmay also show that a concert 0.5 miles away reliably predicts a 70%increase in occupancy but a 50% decrease in turnover. A benefit of thesystem is that as more data is collected, predictions may become morerefined. An aspect of the algorithms is that they may automaticallyadjust predictions related to each of the factors (i.e., time, day,calendar date, events, weather, traffic, and business goals). That is,the algorithms may be self-learning, without requiring additional inputfrom a parking operator or administrator.

Many of the outputs of the above-described algorithms, as well as otherfunctions of the cloud service 500 may be understood through anexplanation of the resulting displays on the parking operator dashboard150 interface. An example of a dashboard screen 700 is shown in FIG. 7.The dashboard screen 700 may include a map 710 showing the location ofeach of the parking operator's parking structures. An aspect of thedashboard screen 700 is that the parking operator may click on eachparking structure and view parking data for that particular structureindividually, as will be shown in other figures. Also shown on thedashboard screen 700 are several “status information” cards 715-719 andseveral “notification” cards 720-724. Status information cards mayinclude current, real-time parking data as well as predicted parkingdata. The relationship between the current, real-time parking data andthe forecasted parking data may be based on the inputs and factors ofthe previously described algorithms. For example, status informationcard 715 shows a current occupancy of a parking area at 46%. At thebottom of that status information card 715, a “1%” and downward arroware displayed to indicate that the current occupancy is down 1% from aprevious period, such as the same time the previous day. Similarly,status information card 516 shows the current turnover of the parkingarea at 57 so far for the day, and down three from a previous period.Status information card 717 similarly shows a reserved occupancy (i.e.,the number of reserved spaces occupied) currently at 73%, which is up26% from a previous period.

The dashboard 700 also shows a number of notification cards 720-724.Notification cards may include weather, event, and traffic informationthat is pertinent to implementing algorithms of the present disclosure.It is contemplated that visual displays of these algorithmic factors mayhelp parking operators intuitively understand the underlying reasons forthe predictions. For example, an impact even notification card 720 showsthat there are 21 “impact events.” These events could include, forexample, nearby sporting events, concerts, conventions, meetings, orother events that could impact the demand for parking that day. Theinformation that generates these impact events may be provided throughone or more commercially available event information APIs.

A violations notification card 721 shows that there are currently 16violations, which may allow the parking operator to issue citationsimmediately. A benefit to providing violation notifications to parkingoperators through this dashboard is that parking operators may beconfident in their ability to issue citations that are both accurate andtimely. The violation notifications are provided in substantially realtime; that is, the violation appears on the dashboard 700 as soon asoccupancy data can be sent from a parking sensor, compared to paymentdata at the cloud service, and relayed to the parking operatordashboard. For example, if a sensor sends occupancy data that a space isstill occupied while the cloud service shows that the payment period hasexpired, the parking operator can be confident that a citation would beaccurate. Further, the parking operator could issue this citationimmediately. It is contemplated that in embodiments of this disclosure,the system may work with third party services that may deliver citationselectronically or by mail, rather than by a human parking officerphysically placing a citation on a car.

A weather notification card 722 shows that there is one weathernotification, which may also be factored into various predictivealgorithms of the present disclosure. Weather information may also beprovided by an API to one or more commercially available weatherservices used by websites and mobile devices. As described previously,weather information can be used to predict whether parking spaces willbe in more or less demand based on previous weather information, otherhistorical data collected, and the implementation of algorithms of thepresent disclosure. The notification cards also include a business goalscard 723 and a surge pricing goals card 724. These notification cardsmay be clicked on to reveal more detailed information about each kind ofnotification, as will be described and illustrated later in thisdisclosure.

An aspect of the present disclosure is that aggregated parking data maybe displayed in a number of different ways in order to make theinformation optimally useful to a particular parking operator. A parkingoperator may choose from a number of different ways to view the datathat is most relevant to the parking operator's business. FIG. 8 shows aline graph view of the dashboard 800. In tins display view, occupancyand turnover are shown on a line graph 810 on an hour-by-hour basis fora particular day. Simultaneously, current occupancy 820 and currentturnover 830 are shown as percentage and numerical values, respectively,at the top of the dashboard. Forecast occupancy 840 and forecastturnover 850 are shown just below current occupancy 820 and currentturnover 830. This view contains the same or similar information as theinformational cards shown in FIG. 7, but in a different visual format.

Several parts of the dashboards 700, 800 may be clicked on to view moredetailed information, or information displayed in a differentlyorganized way. In some embodiments, an operator may choose to displaycertain kinds information instead of others, and may even choose todisplay different kinds of information for different parking areas. Thedisplayable information available to a parking operator may include apercentage of spot occupancy, a turnover rate, current pricinginformation, parking violations, weather, traffic, and event alerts, andother pertinent information.

The dashboard may also include several types of analytics and graphicaldisplays thereof. The graphical displays illustrated in the figures areexemplary only; the information described may be displayed in any numberof ways without departing from the present disclosure. The analyticssections may include more detailed information about individual spots,trends, times, and other useful information, and may be displaced invarious ways in order to facilitate the usage of the data by the parkingoperator. A few examples of graphical displays analytics are shown inFIG. 9. For example, FIG. 9 shows a set of status information cards 900.In the top left corner, a historical view of occupancy card 910 is shownas a line graph over the past 7 days and a percentage (83%) of occupancyover that time. Similarly, on the bottom left corner, a historical viewof turnover card 920 shows a line graph of turnover over the past 7days. The top right corner shows the “front” of a forecast occupancycard 930 (similar to views of status information cards in FIG. 7). Whenclicked, it may display a forecast of occupancy over the next 7 days.The bottom right corner shows a forecast turnover card 940, which showsa line graph of forecasted turnover over for the next 7 days. Theforecast occupancy and turnover data shown are outputs of the algorithmsof the present disclosure.

FIG. 10 shows an display of additional information that may be visibleon the parking operator dashboard when a notification card regardingimpact events is clicked. An impact events display 1000 may show anumber of total impact events 1010. In the present example, 17 impactevents are shown, which may be the number of upcoming events over agiven time period such as a week. The impact events display 1000 mayshow an event name 1020, an event time 1030, and an event location 1040.The display 1000 may also show one or more particular lots 1050. In theexample shown, the particular event, because of its location 1040, islikely to be close enough to impact the three lots shown. A parkingoperator may then click on each individual lot in order to viewpredictions for that lot.

Another benefit of the system of the present disclosure if that aparking operator may view spot-level detail for highly specificinformation. FIGS. 11 and 12 show spot-by-spot spreadsheets 1100, 1200with real-time and historical occupancy information, turnoverinformation, and other information derived from the parking sensors andalgorithms. FIGS. 11 and 12 show a length of current stay for occupiedspots, the average stay of vehicles in that spot for the day, andwhether the vehicle has committed a parking violation. FIG. 12 shows thedata of FIG. 11 in a format sorted by a particular criteria. In theexample in FIG. 12, the data is sorted by which spots have violations.Parking operators may sort by any of the categories of data in order togain insight into problems and opportunities that the operator might nototherwise recognize. For example, if certain spots are nearly alwaysempty, even when the lot is almost full, the parking operator caninvestigate to see whether the spot is hard for customers to access.

FIG. 13 shows yet another graphical interface 1300 that displayshigh-level occupancy and turnover data on individual cards for multiplelots. Each of the cards may be clicked on to view predictive informationor other details for that particular lot.

FIG. 14 shows a detailed view of business goals 1400 that may bedisplayed to a parking operator by clicking on a business goalsnotification card as shown in FIG. 7. A parking operator may set goalsfor turnover, occupancy, and violations over time. Once these goals areselected, the detailed view 1400 may show the operator's progresstowards goals on a daily 1410, monthly 1430, quarterly 1420, and annual1440 basis.

FIG. 15 illustrates an analytics display 1500 that shows even more waysa parking operator can view data collected by the system. As shown, aparking operator can select a date range 1510, select a property 1520,and sort by a number of additional criteria 1530. The parking operatorcan then see the selected data in a line graph. The views shown in eachof the figures herein are just a few examples of the ways operators mayview and analyze all the information available through the system of thepresent disclosure. Many more functions and views are contemplated. Eachof the displays may provide the advantage of making it easier tounderstand and take action on the vast amount of information collectedby the system. For example, recommended surge pricing has previouslybeen discussed as an output of the algorithm. But additionally, becausean operator may be able to view detail about each particular lot in somany different ways, an operator can experiment with their own pricingincreases or decrease and assess the impact on business. For example, aparking operator may be able to experiment with pricing by snakingparking $3 per hour during the day on a Tuesday, and then the next weekmaking it $2.50 per hour during the same times the next Tuesday to seeif his occupancy increases significantly enough to justify the pricedrop. An operator may be able to view the rate of parking violations andthe revenue derived from them. An operator may be able to compare theperformance of each of his or her own lots to each other, or to acompetitor's lots.

The parking operator dashboard 150 may perform all of the functionsdescribed herein, as well as many other functions that may befacilitated by the aggregation of real-time information gathered foreach parking spot owned by a parking operator. Because so much data isavailable to a parking operator, many of the most useful features of thedashboard may relate to how pieces of data are applied to the algorithmsand subsequently displaced. Further, the degree to which a parkingoperator can view, select, and customize the particular data he or shewants to see may be an especially advantageous aspect of thisdisclosure. In embodiments of the disclosure, parking operators can seehow parking structures perform against each another, how individualspots perform against each other, and how current and forecastedweather, price, time of day, month of the year, current and past trafficconditions, special events impact performance, and school schedules,just to name a few examples.

Referring next to FIG. 16, it is a block diagram depicting an exemplarymachine that includes a computer system 1600 within which a set ofinstructions can execute for causing a device to perform or execute anyone or more of the aspects and/or methodologies for static codescheduling of the present disclosure. The components in FIG. 16 areexamples only and do not limit the scope of use or functionality of anyhardware, software, embedded logic component, or a combination of two ormore such components implementing particular embodiments. The computersystem 1600 may be used to implement one or more of the cloud service130, the parking operator dashboard 150, the administration 140, and thegateway 120.

Computer system 1600 may include a processor 1601, a memory 1603, and astorage 1608 that communicate with each other, and with othercomponents, via a bus 1640. The bus 1640 may also link a display 1632,one or more input devices 1633 (which may, for example, include akeypad, a keyboard, a mouse, a stylus, etc.), one or more output devices1634, one or more storage devices 1635, and various tangible storagemedia 1636. All of these elements may interface directly or via one ormore interfaces or adaptors to the bus 1640. For instance, the varioustangible storage media 1636 can interface with the bus 1640 via storagemedium interface 1626. Computer system 1600 may have any suitablephysical form, including but not limited to one or more integratedcircuits (ICS), printed circuit boards (PCBs), mobile handheld devices(such as mobile telephones or PDAs), laptop or notebook computers,distributed computer systems, computing grids, or servers.

Processor(s) 1601 (or central processing unit(s) (CPU(s))) optionallycontains a cache memory unit 1602 for temporary local storage ofinstructions, data, or computer addresses. Processor(s) 1601 areconfigured to assist in execution of computer readable instructions.Computer system 1600 may provide functionality for the componentsdepicted in FIG. 1 as a result of the processor(s) 1601 executingnon-transitory, processor-executable instructions embodied in one ormore tangible computer-readable storage media, such as memory 1603,storage 1608, storage devices 1635, and/or storage medium 1636. Thecomputer-readable media may store software that implements particularembodiments, and processor(s) 1601 may execute the software. Memory 1603may read the software from one or more other computer-readable media(such as mass storage device(s) 1635, 1636) or from one or more othersources through a suitable interface, such as network interface 1620.The software may cause processor(s) 1601 to carry out one or moreprocesses or one or more steps of one or more processes described orillustrated herein. Carrying out such processes or steps may includedefining data structures stored in memory 1603 and modifying the datastructures as directed by the software.

The memory 1603 may include various components (e.g., machine readablemedia) including, but not limited to, a random access memory component(e.g., RAM 1604) (e.g., a static RAM “SRAM”, a dynamic RAM “DRAM, etc.),a read-only component (e.g., ROM 1605), and any combinations thereof.ROM 1605 may act to communicate data and instructions unidirectionallyto processor(s) 1601, and RAM 1604 may act to communicate data andinstructions bidirectionally with processor(s) 1601. ROM 1605 and RAM1604 may include any suitable tangible computer-readable media describedbelow. In one example, a basic input/output system 1606 (BIOS),including basic routines that help to transfer information betweenelements within computer system 1600, such as during start-up, may bestored in the memory 1603.

Fixed storage 1608 is connected bidirectionally to processor(s) 1601,optionally through storage control unit 1607. Fixed storage 1608provides additional data storage capacity and may also include anysuitable tangible computer-readable media described herein. Storage 1608may be used to store operating system 1609, EXECs 1610 (executables),data 1611, API applications 1612 (application programs), and the like.Often, although not always, storage 1608 is a secondary storage medium(such as a hard disk) that is slower than primary storage (e.g., memory1603). Storage 1608 can also include an optical disk drive, asolid-state memory device (e.g., flash-based systems), or a combinationof any of the above. Information in storage 1608 may, in appropriatecases, be incorporated as virtual memory in memory 1603.

In one example, storage device(s) 1635 may be removably interfaced withcomputer system 1600 (e.g., via an external port connector (not shown))via a storage device interface 1625. Particularly, storage device(s)1635 and an associated machine-readable medium may provide nonvolatileand/or volatile storage of machine-readable instructions, datastructures, program modules, and/or other data for the computer system1600. In one example, software may reside, completely or partially,within a machine-readable medium on storage device(s) 1635. In anotherexample, software may reside, completely or partially, withinprocessor(s) 1601.

Bus 1640 connects a wide variety of subsystems. Herein, reference to abus may encompass one or more digital signal lines serving a commonfunction, where appropriate. Bus 1640 may be any of several types of busstructures including, but not limited to, a memory bus, a memorycontroller, a peripheral bus, a local bus, and any combinations thereof,using any of a variety of bus architectures. As an example and not bywax of limitation, such architectures include an Industry StandardArchitecture (ISA) bus, an Enhanced ISA (EISA) bus, a Micro ChannelArchitecture (MCA) bus, a Video Electronics Standards Association localbus (VLB), a Peripheral Component Interconnect (PCI) bus, a PCI-Express(PCI-X) bus, an Accelerated Graphics Port (AGP) bus, HyperTransport(HTX) bus, serial advanced technology attachment (SATA) bus, and anycombinations thereof.

Computer system 1600 may also include an input device 1633. In oneexample, a user of computer system 1600 may enter commands and/or otherinformation into computer system 1600 via input device(s) 1633. Examplesof au input device(s) 1633 include, but are not limited to, analpha-numeric input device (e.g., a keyboard), a pointing device (e.g.,a mouse or touchpad), a touchpad, a joystick, a gamepad, an audio inputdevice (e.g., a microphone, a voice response system, etc.), an opticalscanner, a video or still image capture device (e.g., a camera), and anycombination thereof. Input devices(s) 1633 may be interfaced to bus 1640via any of a variety of input interfaces 1623 (e.g., input interface1623) including, but not limited to, serial, parallel, game port, USB,FIREWIRE, THUNDERBOLT, or any combination of the above.

In particular embodiments, when computer system 1600 is connected tonetwork 1630, computer system 1600 may communicate with other devices,specifically mobile devices and enterprise systems, connected to network1630. Communications to and from computer system 1600 may be sentthrough network interface 1620. For example, network interface 1620 mayreceive incoming communications (such as requests or responses fromother devices) in the form of one or more packets (such as InternetProtocol (IP) packets) from network 1630, and computer system 1600 maystore the incoming communications in memory 1603 for processing.Computer system 1600 may similarly store outgoing communications (suchas requests or responses to other devices) in the form of one or morepackets in memory 1603 and communicated to network 1630 from networkinterface 1620. Processor(s) 1601 may access these communication packetsstored in memory 1603 for processing.

Examples of the network interface 1620 include, but are not limited to,a network interlace card, a modem, and any combination thereof. Examplesof a network 1630 or network segment 1630 include, but are not limitedto, a wide area network (WAN) (e.g., the Internet, an enterprisenetwork), a local area network (LAN) (e.g., a network associated with anoffice, a building, a campus or other relatively small geographicspace), a telephone network, a direct connection between two computingdevices, and any combinations thereof. A network, such as network 1630,may employ a wired and/or a wireless mode of communication. In general,any network topology may be used.

Information and data cats be displayed through a display 1632. Examplesof a display 1632 include, but are not limited to, a liquid crystaldisplay (LCD), an organic liquid crystal display (OLED), a cathode raytube (CRT), a plasma display, and any combination thereof. The display1632 can interface to the processor(s) 1601, memory 1603, and fixedstorage 1608, as well as other devices, such as input device(s) 1633,via the bus 1640. The display 1632 is linked to the bus 1640 via a videointerface 1622, and transport of data between the display 1632 and thebus 1640 can be controlled via the graphics control 1621.

In addition to a display 1632, computer system 1600 may include one ormore other peripheral output device 1634 including, but not limited to,an audio speaker, a printer, and any combinations thereof. Suchperipheral output devices may be connected to the bus 1640 via an outputinterface 1624. Examples of an output interface 1624 include, but arenot limited to, a serial port, a parallel connection, a USB port, aFIREWIRE port, a THUNDERBOLT port, and any combinations thereof.

In addition or as an alternative, computer system 1600 may providefunctionality as a result of logic hardwired or otherwise embodied in acircuit, which may operate in place of or together with software toexecute one or more processes or one or more steps of one or moreprocesses described or illustrated herein. Reference to software in thisdisclosure may encompass logic, and reference to logic may encompasssoftware. Moreover, reference to a computer-readable medium mayencompass a circuit (such as an IC) storing software for execution, acircuit embodying logic for execution, or both, where appropriate. Thepresent disclosure encompasses any suitable combination of hardware,software, or both.

Those of skill in the art would understand that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Those of skill would further appreciate that the various illustrativelogical blocks, modules, circuits, and algorithm stops described inconnection with the embodiments disclosed herein may be implemented aselectronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, modules, circuits, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. Skilled artisans may implement the describedfunctionality in varying ways for each particular application, but suchimplementation decisions should not be interpreted as causing adeparture from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a general purpose processor, digital signal processor(DSP), an application specific integrated circuit (ASIC), a fieldprogrammable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof DSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

The steps of a method or algorithm described in connection with theembodiments disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module may reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such the processorcan read information from, and write information to, the storage medium.In the alternative, the storage medium may be integral to the processor.The processor and the storage medium may reside in an ASIC. The ASIC mayreside in a user terminal. In the alternative, the processor and thestorage medium may reside discrete components in a user terminal.

The previous description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentdisclosure. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the disclosure. Thus, the present disclosure is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the principles and novelfeatures disclosed herein.

What is claimed is:
 1. A parking sensor device comprising: a low-powerradio transceiver, a sensor for detecting a presence of a vehicle; and aprocessor that is in communication with the low-power radio transceiverand the sensor, wherein the processor is configured to: activate thelow-power radio transceiver in response to the sensor detecting thevehicle; communicate directly with a consumer's personal communicationdevice using the low-power radio transceiver; and transmit, via thelow-power radio transceiver, parking data to the consumer's personalcommunication device.
 2. The parking sensor device of claim 1, whereinthe parking sensor device is configured to be installed in a parkingspace such that when a vehicle parks in the parking space, the vehicleis located directly above the parking sensor device.
 3. The parkingsensor device of claim 1, further comprising an outer housing, whereinthe low-power radio transceiver, the sensor, and the processor arehoused within the outer housing.
 4. The parking sensor device of claim3, further comprising a surface mount ring that mounts around the outerhousing.
 5. The parking sensor device of claim 4, wherein the surfacemount ring has an inner radius and an outer radius, the inner radiusfitting around a top outer edge of the outer housing.
 6. The parkingsensor device of claim 5, wherein an exterior surface of the surfacemount ring comprises ridges or a textured pattern.
 7. The parking sensordevice of claim 1, wherein the low-power radio transceiver is aBluetooth Low Energy (BLE) transceiver.
 8. The parking sensor device ofclaim 1, wherein the sensor for detecting the presence of the vehicle isa magnetometer.
 9. The parking sensor device of claim 1, furthercomprising a second radio transceiver that is configured to communicatewith a gateway system.
 10. The parking sensor device of claim 1, whereinthe parking sensor device is further configured to send a periodicinformation update to a gateway system.
 11. A parking sensor system,comprising: a plurality of parking sensor devices, wherein each parkingsensor device of the plurality of parking sensor devices comprises: oneor more radio transceivers, a sensor for detecting a presence of avehicle; and a processor that is in communication with the one or moreradio transceivers and the sensor, wherein the processor is configuredto: activate a radio transceiver of the one or more radio transceiversin response to the sensor detecting the vehicle; communicate directlywith a consumer's personal communication device using the radiotransceiver; and transmit, via the radio transceiver, parking datadirectly to the consumer's personal communication device; and a gatewaysystem, wherein the gateway system communicates with the plurality ofparking sensor devices via the one or more radio transceivers to receiveparking data.
 12. The parking sensor system of claim 11, wherein thegateway system receives a periodic information update from each parkingsensor device of the plurality of parking sensor devices.
 13. Theparking sensor system of claim 11, wherein each parking sensor device ofthe plurality of parking sensor devices further comprises: an outerhousing, wherein the one or more radio transceivers, the sensor, and theprocessor are housed within the outer housing; and a surface mount ringthat mounts around the outer housing, wherein the surface mount ring hasan inner radius and an outer radius, the inner radius fitting around atop outer edge of the outer housing.
 14. The parking sensor system ofclaim 11, wherein the sensor for detecting the presence of the vehicleof each parking sensor device of the plurality of parking sensor devicesis a magnetometer.
 15. The parking sensor system of claim 11, furthercomprising: a cloud service component that receives parking data fromthe gateway system and provides the parking data to a parking operatordashboard web interface.
 16. The parking sensor system of claim 15,wherein the gateway system comprises a long-range wireless transceiverand a local wireless transceiver, wherein the local wireless transceiveris used for communicating with the plurality of parking sensor devicesand the long-range wireless transceiver is used for communicating withthe cloud service component.
 17. The parking sensor system of claim 11,wherein the radio transceiver of each parking sensor device of theplurality of parking sensor devices is a Bluetooth low energy (BLE)transceiver.
 18. The parking sensor system of claim 11, wherein eachparking sensor device of the plurality of parking sensor devicescomprises a second radio transceiver of the one or more radiotransceivers is used to communicate with the gateway system.
 19. Theparking sensor system of claim 18, wherein the second radio transceiveruses WiFi to communicate with the gateway system.
 20. The parking sensorsystem of claim 11, further comprising the consumer's personalcommunication device, wherein the consumer's personal communicationdevice executes an application that receives a parking space identifieras part of the parking data from a parking sensor device of theplurality of parking sensor devices.